Numerous electronic circuits and systems are utilized to perform useful tasks. In the performance of these tasks, the electronic circuits and systems often communicate with one another via a communication bus. One type of communication bus is the inter-integrated circuit bus (I2C bus). The I2C bus provides a communication link between integrated circuits (ICs) and electronic systems. Traditionally, an I2C bus consists of two active wires referred to as the serial data line (SDA) and serial clock line (SCL).
Prior Art FIG. 1 is an illustration of I2C bus system 100 configured in an exemplary conventional arrangement wherein a management processor 110 manages communication access on I2C bus 115. The I2C bus 115 comprises an SCL line 112 and an SDA line 114 that provide bi-directional communication paths which are coupled to modular field replaceable units (FRUs) 120, 121, and 122. Pull-up resistors 135 and 137 are coupled to SCL line 112 and SDA line 114 respectively to establish a default state on each line. The FRUs can be a variety of components including a server blade, a server card, a driver, a memory, or complex function IC. The I2C bus can be used with an intelligent platform management interface (IPMI) or other I2C protocols.
Conventional I2C buses utilize a master-slave or master-master communication protocol for transmitting packets (e.g., well defined blocks of data comprising a header, data and a trailer) between devices coupled to the bus. Components (e.g., FRUs) coupled to the I2C bus have a unique address and can behave as a sender or receiver of data (e.g., depending on specific functionality of the device). With IPMI, each “intelligent” device on the bus acts as a master and utilizes a master-master communication protocol. A component (e.g., FRU 120), attempting to transmit information on the I2C bus while another master (e.g., the management processor) controls the bus, must adhere to the arbitration rules of I2C. Essentially, all devices that are attempting to gain control of the bus must also monitor the bus and back off as soon as the signals do not match what the individual device is attempting to write. Because the bus is pulled high by pull-up resistors, and only driven low by active devices, the device driving low wins control of the bus.
One major concern for communication systems is security maintenance. Preventing unintended and/or unauthorized entities from accessing information communicated on a bus is usually desirable. However, traditionally it is usually possible for unintended components to spoof communications on I2C busses. For example, communications on an I2C bus in a common chassis (e.g., a host-client situation wherein slots are rented in a common chassis) intended for components utilized by a first entity (e.g., a first company) can be received by another component utilized by a second entity (e.g., a competing company). More specifically, it is possible for a device to “spoof” the I2C bus to deliberately receive data (e.g., a competitor's confidential information) that was not destined for the particular “spoofing” device.
There are a number of issues that arise in maintenance of traditional I2C bus systems. For example, if there is a bus failure on a segment of an I2C bus, communications are typically lost to the components coupled to the bus even if the components are not on the segment that is lost. To provide proper maintenance it is usually beneficial to have a good understanding of the type and number of devices coupled to an I2C bus and traditionally this is manually performed which is labor intensive and often inconvenient, especially if the components are remotely located. It is also usually difficult to discover errors in a system and provide corrective directions. For example, it is traditionally difficult to detect and remedy a situation in which one device effectively “captures” the bus by becoming a master and continuously transmitting information to prevent others from using the bus. Capacitance characteristics of devices coupled to an I2C bus also often can make maintenance and reconfiguration difficult.
Components coupled to an I2C bus usually create a capacitive load on the I2C bus, which together with the pull-up resistors produce RC constant characteristics that impact attributes of signals communicated via the I2C bus. For example, signal waveforms can be altered and the ability of components to distinguish between logical ones and zeroes impacted. As a result, it is desirable maintain an appropriate balance between the capacitive and resistive characteristics of the I2C bus lines. However, maintaining a capacitive and resistive balance can be difficult when adding or deleting components dynamically since the number and type of components on a bus impact the capacitive characteristics. Traditional attempts at achieving a balance usually limited the number of components coupled to an I2C and often involve costly bus redesign, which if done incorrectly can cause bus interrupts, or possibly catastrophic bus failure.
In current I2C bus systems, each component is assigned an I2C address. For example, with reference to FIG. 1, FRU 120, FRU 121 and FRU 122 each have an assigned I2C address. As described above, consider a situation where FRU 120 is operated by the first entity and FRU 121 is operated by the second entity. If the second entity desires to access data being transmitted to FRU 120, FRU 121 may spoof current I2C bus systems into believing it is FRU 120 by using the I2C address of FRU 120.
Another issue with the conventional I2C bus is that since only one device is allowed to transmit data on the bus at a time, only one communication at a time on the bus is possible; i.e., multiple, simultaneous communication from the master to multiple slaves as with a data hub, for example, is not possible.
The I2C bus according to the conventional art also suffers from the inability to detect the presence of a device (e.g., field replaceable unit) coupled thereto, the inability to determine if the device coupled thereto is functional and/or the inability to reset the device when an error occurs. Furthermore, the I2C bus according to the conventional art also suffers from the inability to provide for readily analyzing and debugging data traffic on the I2C bus. The serial two-line I2C bus is difficult to trap events on, because a serial data pattern must be trapped. In addition, it is also difficult to detect what device is the source device; only the destination device address can readily be trapped.